Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-191 < prev next >

Wrap

Text File | 1988-12-01 | 26.9 KB | 639 lines

Internet Experiment Note: 191 C. Sunshine D. Cohen J. Postel ISI July 1981 Comments on Rosen's Memos INTRODUCTION This memo comments on recent IEN's by Eric Rosen of BBN (numbers 182, 183, 184, 187, 188, 189) [1,2,3,4,5,6]. We think these notes raise some important and interesting issues which require further discussion. In the following we focus on the points of disagreement (but don't assume that we agree with something simply because we don't mention it here). After a brief general comment we discuss each note in turn. There are some good points raised in this series. Unfortunately the presentation is both verbose and incomplete. There is nothing wrong with taking a certain aspect of a topic and exploring it at length, but these memos seemingly present all available alternatives and select the "best" for further development. Our concern is that, in fact, not all alternatives are studied, and not all evaluation criteria are given the proper weight in selecting the "best" alternative. A minor problem is the informality of the references. It is unclear exactly which earlier memos, reports, and papers the author has in mind in some of the discussion, and it is unclear if the author is aware of some very relevant material. In some sections it appears that the author is unfamiliar with much of the relevant material, and hence fails to include important points in his presentation. IEN 182 This note on "Issues in Buffer Management" is, in the main, a description of buffer management in the ARPANET IMPs. This is quite useful and should be food for thought for gateway designers and implementers since gateways may have some of the same constraints and concerns in buffer management as IMPs. However, the differences that do exist in the goals for gateways and IMPs are not taken into account, so the policies adopted for IMPs are not necessarily appropriate for gateways. Differences in the level of reliability of delivery, and the end-to-end virtual circuit vs. the datagram style of service can lead to substantial differences in the requirements for buffer management. This is a useful memo in that it exposes a good deal about the buffer management polices used in the ARPANET IMPs, information that is not easily found elsewhere. But it is contains some weakly supported Sunshine & Cohen & Postel Page [1] July 1981 IEN 191 Comments on Rosen's Memos overly broad conclusions that seem to ignore and sometimes contradict existing results in this area. IEN 183 This memo presents a proposal for a logical addressing mechanism in the ARPANET, and includes a good deal of discussion of alternatives. Interested readers should see earlier IEN's on the subject from MIT, ISI, and Xerox, plus the classic paper by Shoch, and recent work on "naming authorities" at Xerox, which the author fails to credit or reference [7,8,9]. We prefer the more commonly used term "name" to the phrase "logical address" which the author uses. The key proposal is to include a name-to-address lookup function in the source switches of a network so that the "user" will not have to supply ("physical") addresses. This seems a worthwhile goal, but the meaning of "user" seems confused between (1) people or application programs using the network, and (2) network access software (such as NCP or TCP) supporting (1) in the hosts. The author seems oblivious of this distinction. Everyone agrees that category (1) "users" should be able to use names. Of course, most ARPANET hosts' category (2) software already provides this function (the host table) for category (1) "users". The proper discussion should be whether this function is best located in the switches, or in the network support software of the hosts, but this is not explicitly addressed by the author. The author presents a reasonable approach to implementing a name lookup function without requiring broadcast of dynamic changes to all participants. A basic table of all potentially usable addresses for each name must be distributed to all parties (the "authorized" table), but this is expected to change relatively slowly. Entries in this table are assumed usable ("effective") until an explicit exception message ("destination not accessable") results from using them. The unusable markings are reset after a time interval. We agree that this is a worthwhile proposal, but the placement of this function in the hosts, the switches, or a separate name lookup service needs further discussion. Since most hosts are already performing this function as noted above, it is clearly within their capabilities. An advantage of placement in the switches seems to be prevention of "spoofing" since hosts can only send/receive messages from/for a specified name if that name is "authorized" for the Page [2] Sunshine & Cohen & Postel IEN 191 July 1981 Comments on Rosen's Memos addresses they are physically attached to. Of course this requires source and destination switches to check messages in a "trusted" fashion. There is a small inconsistency in the author's discussion of source-only vs. intermediate ("tandem") node name lookup. At the top of page 11, it is stated that the tandem nodes will be "no more likely" than the source node to have new information during a transient update period. However, on page 12-13, it is pointed out (correctly) that tandem nodes likely WILL produce a "better route selection ... if delay changes or topology changes take place while a packet is in transit." There will be substantial modification needed to the host software in order to implement this scheme. It is proposed (we think) that both the current scheme and the logical address scheme be available at the same time. The details of the logical address are not very clear, but a 16-bit logical address is suggested, which would require a character string to number lookup in the hosts to make it convenient. IEN 184 This memo claims that the previous work on the Internet is deficient due to reliance on an inadequate model of the structure of the Internet. IEN 184 claims to present a new model of the Internet that does provide a basis for future work. The proposed model of internetwork operation views the gateways more explicitly as switching nodes, with the hosts attached to these nodes. In particular, each host is multi-hommed on all the gateways on the same network as the host. There is some merit to this model and the questions it raises, but the author is not the first to think of this viewpoint (see for example IEN-135 [10]). There are also some problems with this model that the author seems unaware of. This new model might be acceptable if one wanted to build a super ARPANET based solely on lines and super-IMPs, but if one is planning to include other technologies such as broadcast satellite and broadcast local networks, the proposed model has serious flaws. For example, two hosts on the same net may still wish to use Internet protocols to communicate. In the author's model, they would have to do so by going through an intermediate gateway on their net, since by definition, no hosts can communicate directly over a "Pathway" with Sunshine & Cohen & Postel Page [3] July 1981 IEN 191 Comments on Rosen's Memos no intervening "Switch." This is clearly inefficient in the intranet case, and one way in which it differs from the ARPANET. This would also be true in many single broadcast nets where there are no intervening switches between hosts even at the single network level of "Network Structure." This memo fails to consider the impact on the host systems. Host will be designed to use a common approach to communication with other hosts whether they be across the room or across the world. With the existing model and Internet Protocol, the same procedures and formats can be used between hosts on the same network and between hosts many networks apart (though different performance parameters may be necessary). The model developed in the Internet Working Group and described by Cerf (IEN-48 [11]) continues to be the most reasonable basis for developing the Internet. IEN 187 This memo assumes the model (of IEN 184) of hosts always sending and receiving internet traffic via an "Internet Switch". It goes on to describe the interactions of a host and an internet switch, and then criticizes the existing Internet Protocol for not being a perfect host-switch interface protocol. We cannot possibly take on all of the topics and "lessons" presented, but Section 2.4 of IEN-187 on fragmentation provides a good example of what is wrong with these reports. Again, the author seems unaware of previous important work on this subject, for example IEN-20 by Shoch (expanded and published in Computer Networks in 1979) [13], or the paper by Sunshine on interconnection of networks published in Computer Networks in 1977 [14]. If the author had read these, he might have avoided several serious deficiencies in his presentation: 1. After a long discussion of the evils of final destination (or internet) fragmentation, the author reveals his preferred approach of hop-by-hop (or intranet) fragmentation as if he invented the idea. 2. There is an important goal that internet fragmentation supports, but intranet fragmentation does not: independent and possibly different routing of each fragment through different exit gateways from a "small packet" net (and subsequently). The author fails to consider this point. Page [4] Sunshine & Cohen & Postel IEN 191 July 1981 Comments on Rosen's Memos 3. In presenting scenarios (page 58) showing the evils of internet fragmentation, the author omits the important scenario of several small packet nets in a row, where repeated intranet fragmentation is just the WRONG thing to do. 4. Packets with the Don't Fragment flag on are not "simply lost in transit" (page 53) if they cannot be forwarded without fragmentation. Specific error packets are returned to the source host, which may try to resend smaller packets. 5. After all his discussion, the author admits in the final paragraph that destination host fragmentation is necessary anyway if the final network gets too large a packet. The author claims this will be necessary only for hosts on nets with "unusually small" maximum packet sizes, but in fact it will be necessary on all nets with less than the maximum maximum packet size of any net in the system if they wish to receive packets from the largest packet size nets. The net effect of this sort of incomplete presentation is a step backward from the current imperfect level of understanding of this important issue. The author also attacks the Type of Service (TOS), Time to Live (TTL), Source Routing (SR), Flow Control (FC), and Fault Isolation (FI) features of IP and ICMP. On Type of Service the author tells us for ten pages all the bad things about the Internet Protocol provision for TOS, while agreeing it is an important concept, but has nothing different to offer, except some vague notion that service catagories should correspond more closely to application types. On Time to Live the author complains that there is an inconsistency since the TTL is stated to be in seconds, and that the gateways must decrement the TTL by one, and that the gateways are expected to process datagrams faster than one a second. If one assumes that the intention is to guarantee that datagrams stay alive as long as the TTL, he is right. But the intention is really to guarantee that they disappear before TTL. So TTL is an upper bound on how long the datagram may exist. Most reliable transport protocols assume a maximum datagram lifetime (sometimes unknowningly) for the correct operation of their reliability procedures [15]. On Source Routing the author suggests that this feature exists due only to problems with existing routing procedures and for Sunshine & Cohen & Postel Page [5] July 1981 IEN 191 Comments on Rosen's Memos experiments, and that any really adequate routing procedure in the gateways will eliminate the need for source routing in normal operations. We suggest that the Internet will be a much more dynamic environment than the author has yet imagined and that source routing will be essential to reach through the Internet to local environments not fully integrated into the main Internet routing world. On Flow Control and Fault Isolation the author indicates that the current mechanisms are inadequate, but does not suggest workable alternatives. On FC the ICMP "Source Quench" message is cited as a case of "choke packet" flow control which the author does not believe in (page 64). Earlier (page 63) the author complains that "source quench" is only advisory, and later (page 66) the author makes vague suggestions that a better flow control scheme would use advisory messages to suggest that datagrams had been discarded (exactly what source quench does). All in all this memo comes across as an attack on the Internet Protocol, with few suggestions for improvement. But it is based on an assumption: that the Internet Protocol is a host-switch access protocol. This assumption requires further discussion. IEN 188 This memo describes logical addressing in the Internet, primarily by recasting the method of IEN 183 in generalized terms. There are a number of inaccuracies and omissions in the discussion. One serious limitation is failure to consider the case of hosts sending Internet datagrams to each other directly on a single net as discussed above. On page 4 (middle), the author correctly states that IP addresses are hierarchical, but incorrectly states that their second component is necessarily a "physical address." In fact, it may be a name or "logical address" in networks that provide that capability (but must be carried in 24 bits). On page 7, the author proposes using a "unique name which is meaningful at each level of internet hierarchy." This seems to be a strong violation of layering, and as the author admits, would require the switches in every constituent network to "understand" and be able to lookup the names, probably an intolerable demand on individual network autonomy. On page 34, the author's claim that hierarchical addressing requires less table space than flat addressing is false. His justification is incomprehensible to us, particularly since he has just finished Page [6] Sunshine & Cohen & Postel IEN 191 July 1981 Comments on Rosen's Memos proposing an "area" addressing scheme similar to hierarchical schemes in order to reduce table sizes! In the detailed model of operation given in Section 3.4, an important step is omitted when the first sentence states, "Let's assume that a source Host has given a message to a source Switch ..." How does the source host pick the source switch? In fact, it must pick both a network level (e.g., IMP) and internet level (gateway) switch, assuming it is multi-homed, which at least at the internet level is quite likely. In order to make this selection, the host will have to have a table giving the best switch (at each level) for each possible destination name. But these are precisely the sort of tables the author's scheme is meant to avoid having in the hosts. In light of the comment above about hosts talking to each other directly on the same net, the hosts must at least know the names and addresses of every other host on their own net. The treatment of mobile hosts is quite brief and offers no improvement over previously proposed solutions. IEN 189 This memo discusses routing in the Internet, and proposes that the existing gateway routing procedure be replaced by the SFP procedure now used in the ARPANET. This is surely a useful suggestion. The note does however raise a number of issues in its examples of routing problems that indicate an incomplete understanding of the whole area. The note proposes a "gateway discovery protocol" that could be provided by individual nets. This idea seems worthwhile, although it is not clear how many individual nets would be willing to make such additions. We should like to point out that it is also possible to perform this function directly among gateways in networks which support broadcast or group addressing. The discussion of routing alternatives makes generally sound if qualitative conclusions, but a few details are confused. The discussion of throughput performance on page 41 assumes TCP will operate with a small enough window over a high delay path so that throughput is reduced, but this is precisely the situation in which proper "tuning" requires a large window, which would allow high throughput. The analogy with "whole picture" algorithms on pages 44-45 fails to mention that in the whole picture scenario, each person would have to get a piece of paper 100 times bigger than with the local scheme, and Sunshine & Cohen & Postel Page [7] July 1981 IEN 191 Comments on Rosen's Memos hence this approach has an information distribution requirement that is much higher. This memo contains several informal citations that could be usefully spelled out for the IEN audience. The author mentions algorithms by Gallager (page 17), Dijkstra (page 20), and Floyd (page 20), all without references. It is safe to say that any list of references containing only the author and his coworkers (as consistently done in this series) cannot be adequate. One particular example provokes the following response: Please replace the second paragraph of page 49 of IEN-189 with the following paragraph: "In fact the situation could be even worse. If Switches in Boston know nothing about what happening inside the building on 4676 Admiralty Way then data for the North section of the 11th floor which arrives at the South section of the 11th floor is then sent back from the South section to Boston for alternate routing will just loop back to the South section. The data will be stuck in an infinite loop, never reaching its destination. In IEN 179 [12] Danny Cohen proposed a regional scheme like this, apparently not realizing that it suffers from loops. His proposal also includes a form of hierarchical addressing which is closely bound up with routing, so that a Switch is Boston might not even be able to distinguish data for the South section from data for the North section. That is, in Cohen's scheme, data for the South section and data for the North section would be indistinguishable at the Boston Switches; all such data would appear to be addressed to the South section. Only the Switches at the South section would look further down the address hierarchy to determine whether the data needs further forwarding to the North section. Any such scheme is hopelessly loop-prone, except in a Network Structure whose connectivity is extraordinarily rich, much more so than the Catenet's will ever be." Since the above suggestion was merely to follow the routing strategy used by the phone companies, TELENET and others, you should warn them immediately about this hopelessly loop-prone situation. I believe that if the Boston Switch has ALL the information about EVERYthing, EVERYwhere it would be in position to make better decisions, ALWAYS, especially if that information is updated with Page [8] Sunshine & Cohen & Postel IEN 191 July 1981 Comments on Rosen's Memos absolutely ZERO time delay. If this information is absolutely free (in terms of communication, storage and processing) it may be dumb not to make every Switch always know everything about everything, down to (or "up to"?) the finest granularity (location? site? process? file? register? bit?). However, if this is not absolutely free, some compromises may have to take place. Oh, one point which I did not quite follow: why if the Nevada/California lines are broken forever, Boston is never told about it - as described by you? By the way, what made you understand that the "The Switch at Nevada would look further down the address hierarchy to determine whether the data needs further forwarding to California" ? I highly recommend that you get hold of any telephone directory and read the area-codes tables. This may help you understanding that the California area codes are neither above, nor below, nor further on any hierarchy than the Nevada ones, and vice versa. This is a very subtle point which may escape the casual reader. Mastering this idea may help you understand what IEN-179 is all about. In short, IEN-179 is not an attempt to describe the ideas which you have in mind by using the telephone scenario, but an attempt (which obviously failed, at least in your case) to introduced old well-proven ideas from other communication arenas into ours. SUMMARY In summary we are glad to have this information and these opinions presented for discussion in the Internet Working Group, and we hope that others will speak up with their opinions too. We are concerned that too many will be so overwhelmed by the wide ranging arguments to notice that some important considerations were not mentioned. We especially want to make clear that a fundamentally different model of the Internet architecture is proposed by Rosen, and that we have serious reservations about aspects of that model. Sunshine & Cohen & Postel Page [9] July 1981 IEN 191 Comments on Rosen's Memos REFERENCES [1] Rosen, E., "Issues in Buffer Management", IEN 182, Bolt Beranek and Newman, May 1981. [2] Rosen, E., "Logical Addressing", IEN 183, Bolt Beranek and Newman, May 1981. [3] Rosen, E., "Issues in Internetting Part 1: Modelling the Internet", IEN 184, Bolt Beranek and Newman, May 1981. [4] Rosen, E., "Issues in Internetting Part 2: Accessing the Internet", IEN 187, Bolt Beranek and Newman, June 1981. [5] Rosen, E., "Issues in Internetting Part 3: Addressing", IEN 188, Bolt Beranek and Newman, June 1981. [6] Rosen, E., "Issues in Internetting Part 4: Routing", IEN 189, Bolt Beranek and Newman, June 1981. [7] Clark, D., "A Proposal for Addressing and Routing in the Internet", IEN 46, MIT/Laboratory for Computer Science, June 1978. [8] Cerf, V., "Internet Addressing and Naming in a Tactical Environment", IEN 110, Information Processing Techniques Office, Defense Advanced Research Projects Agency, August 1979. [9] Shoch, J., "Inter-Network Naming, Addressing, and Routing", Proceedings 17th IEEE Computer Society International Conference, pp72-79, September 1978. [10] Sunshine, C., "Addressing Mobile Hosts in the ARPA Internet Environment", IEN 135, USC/Information Sciences Institute, March 1980. [11] Cerf, V., "The Catenet Model for Internetworking", IEN 48, Information Processing Techniques Office, Defense Advanced Research Projects Agency, July 1978. [12] Cohen, D., "Addressing and Routing", IEN 179, USC/Information Sciences Institute, March 1981. [13] Shoch, J., "Packet Fragmentation in Inter-Network Protocols", Computer Networks, V.3, N.1, pp3-8, February 1979. Page [10] Sunshine & Cohen & Postel IEN 191 July 1981 Comments on Rosen's Memos [14] Sunshine, C., "Interconnection of Computer Networks", Computer Networks, V.1, N.3, pp175-195, January 1977. [15] Watson, R., "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, V.5, N.1, pp47-56, February 1981. Sunshine & Cohen & Postel Page [11]